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ABSTRACT 



In a computer video conferencing system it is often neces- 
sary to transmit multiple channels of information between 
remote computers, such as a video channel, an audio channel 
and data sharing channel. A socket based transport interface 
can be utilized to establish communication channels 
between remote computers over a connection oriented tele- 
phony network. A plurality of sockets are created at each 
endpoint, one for each type of data stream to be transferred 
between the computers. The sockets are formed into a group 
to indicate to the computer transport service provider mat 
the data streams from the sockets can utilize the same 
telephony connection, and a quality-of-service specification 
is associated with the socket group so that the telephony 
connection can be established according to the requirements 
of the socket group. If a new data stream needs to be 
transmitted and there is already a telephony connection 
established, a new socket is created and added to the existing 
socket group. If the newly added socket significantly affects 
the quality-of-service requirements of the socket group, a 
new quality-of-service may be negotiated with the telephony 
network. 

13 Claims, 5 Drawing Sheets 
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MECHANISMS FOR ACCESSING UNIQUE tions which, for example, create a socket bind a name to the 

FEATURES OF TELEPHONY NETWORKS created socket, establish a connection to another socket (for 

FROM A PROTOCOL-INDEPENDENT DATA a stream-data socket) or transmit data packets (for a data. 

TRANSPORT INTERFACE gram socket, together with related functions. 

BACKGROUND OF THE INVENTION 5 Most ^^P 0 * interfaces, such as the BSD Unix 

« <n> u £ ,i — (™) sockets interface and the WinSock fTM) API men- 

1. Held of the Invention tioned above, support the notion of multiple coxmiumica- 
This invention relates to the field of telecommunications ti°°s endpoints or communications channels being mnlti- 

between computers, such as may be employed in confer- plexed together across a single network interface. While 

encing between remote computer systems interconnected by 10 current data transport interfaces work well for both local 

way of a connection-oriented telephony network. area networks (LANs) and wide area networks (WANs) that 

2. Background employ connectionless networklayer protocols (e.g. TCP/IP, 
As computers and the capabilities of telecommunication E^GOTX, etc.), there are a number of problems exposed in 

systems become more powerful, and computer systems utilizing the same communication methods for connection- 
become more heavily networked, there is an increasing need 15 Exited network layer protocols typical of telephony net- 
far computers to provide mechanisms by which the capa- works - It would therefore be advantageous to provide meth- 
bilities of the telecommunications systems can be more fully °^ and mecnanisms °y which interprocess communication 
exploited. can be effected by way of a connection-oriented telephony 
Presently, communication between two computer pro- ™ * eX ? loit of telephony net- 
cesses can be implemented by utilizing a "socket" mecha- W n0t avaiIable or not required in a connectionless 
nism. A socket as popularized in the Berkeley Software nCtWOrk SUCh as a LAN or WAN. 
Distribution (BSD) of implementation of the Unix (TM) SUMMARY OF THE INVENTION 

conges ordinary file-system path names, such as/alpha/ plenty of socket communSnSTteTTf ^ S 

53*^ as ™* CTransmhsion-Control by way of said^connection-orieLd He£yTeSork 

>! •*««•«. wbid > between said first and second computers, said telephony 

consist of a 32-bit host munber and a 16-hit port number. connection having a quality-of^ervfce at least equal to said 

S35n^J " 8 * e t same computer « comprising a second plurality of socket communiStion 

I ^v^^t M ^ ^ eStabU f h " «- by Lid at least on? e™^uter 

lofw^ ^ V , d °T n aDd 8 P rocess ° n st "d second computer, and establishing aZni 

logical connecboa therebetween for data to pass from one to ity of communication chapels between each of sawTst 

rr\ ' ... plurality of sockets and corresponding ones of said second 

Two processes which operate on separate but inter net 45 plurality of sockets; and transmitting a plurality of data 

ISl^ c0 J n f um ^ te r with ° ne «™»« by streams between said at least one first process on said first 

^ctve sockets u. the Internet domain. Data computer and said at least one second process on said second 

r^oeS tJES il 0 ^ 8 *L Way ° f . the COmputer ^ Wfl y of said P 1 *^ of communication chan- 

respectiye sockets by either connecHon-onented stream-data nels multiplexed on said telephony connection 

^sZl^^JT^tZ^L^'f, PaCk V 50 ^ fonnfltion of socket communication endpoints into 

SSbfe £?^T??L**°- ■ 80Cket ^ interface to ded with the 

XEtS^iS? » connection transmission of data betweentoe grouped sockets more 

irom one socket to another across the netwrrk is ettnhlfchrri .<r-:.->i.. • . . ^ " 

accorrfiro t n «... iJT^ , ^ efficientty in a connection-oriented communications 

according to the Interne Protocol (TCP/IP) addressing environment, because data streams from erouped sockets 

^il?™ g C r PUter ? < *f nto UDder ,he P* 01 ** fOT each «cket designating the relate importance 

Mndows (TM) operating , system to implement a socket of the date stream from that socket for traiisimssionWeTme 

^ SD xVT i??- 1116 WinS ° Ck <™> tele P hon y connection. In some instances the bandwidth of 
uEEIS^ ^"T 1 ;^ > Which is a 65 tte tde P hon y connection for data transmission may be less 

Uhrary of fimctions that enable an application to utilize than the instantaneous combined bandwidth of data streams 

TCP/IP socket communication capability by providing func- from the sockets comprising the socket group, in which case 
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transmission of one or more of the data streams may need to mined address, and monitoring progress of the call accord- 
be suspended or reduced. By assigning relative priorities to ing to signals received from the telephony network in 
the sockets within the group, the transport interface can response to placing the call. 

determine which data stream to suspend, being the data Other features and advantages of the present invention 
stream originating from the socket with the lowest assigned 5 ^ ^ app^^ from the appended claims, and from the 
priority. Thus, in one aspect of the invention the method may &&&& description of the invention that follows below, 
additionally include a step of temporarily suspending trans- 
mission of data from a socket having a lowest assigned BRIEF DESCRIPTION OF THE DRAWINGS 
priority amongst said and second plurality of sockets com- 
prising said first and second socket groups. 10 The invention is described in greater detail hereinafter, by 
An example of where the method of the invention can be way of example only, with reference to the accompanying 
advantageously employed is a computer conferencing drawings in which: 

system, wherein video data, audio data and graphical and/or FIG. 1 is a block diagram of a computer video confer- 
text data is transmitted via a telephony connection between encing hardware arrangement in accordance with a preferred 
two computers. In this instance a separate socket commu- ^ embodiment of the present invention; 
nication endpoint is created at each computer for each of the pjQ 2 is a block diagram of a software structure used in 
video, audio and graphics/text data streams, and connections the preferred embodiment of the invention; 
established between the respective sockets by way of the pj GS 3, 4 ^ 5 are flowcharts illustrating communica- 
telephony connection. The separate data streams are mum- tion m accordance with the preferred embodi- 
plexed for transmission over the telephony connection and, 2 o men ^ 
in normal operation, the bandwidth of the telephony con- 
nection is shared between all of the data streams from the DETAILED DESCRIPTION OF THE 
sockets comprising the socket groups associated with the PREFERRED EMBODIMENT 
conferencing application. Priorities for the sockets are 

assigned according to the importance of the data streams to The present invention is described in detail hereinbelow 

be transmitted therefrom. In this example, the socket asso- by reference to a preferred embodiment thereof which 

dated with the audio data stream may be assigned the comprises a conferencing system as may be employed to 

highest priority, the socket for passing graphics/text the next communicate signals between remote computer systems. In 

higher priority, and the video data socket the lowest priority. the following description, numerous specific details are set 

Therefore, if the bandwidth of the telephony connection was 30 forth in order to provide a thorough understanding of the 

not sufficient to pass all three data streams, the assigned invention. However, it will be apparent to one of ordinary 

priorities provide the transport interface with information skill in the art that these specific details need not be used to 

sufficient to make a derision as to which socket supplies data pn"^ the present invention. In other instances, well 

which, if transmission were suspended, would have the least known structures, circuits, and interfaces have not been 

impact on the operation of the conferencing system. 35 shown in detail in order not to obscure unnecessarily the 

In some telecommunications systems such as Integrated present invention. 
Services Digital Networks (ISDN) and Asynchronous Trans- Referring now to FIG. 1, there is shown a block diagram 
fer Mode (ATM) networks, it is possible to take particular of computer system and telecommunications hardware 
advantage of the ability provided by the present invention to which may be employed to implement a conferencing sys- 
specify a quality-of-service for a socket group since it is 40 tern according to an embodiment of the invention. A first 
generally possible to specify the required characteristics of computer system 10 (sometimes referred to as the local site 
a telephony connection at the time the connection is estab- or endpoint) is provided, having a processing unit (CPU) 
lished. Thus, when a telephony connection established in 100A which may comprise, for example, a personal corn- 
order to service the transmission of data streams between puter based on an 80x86 microprocessor or Pentium (TM) 
groups of socket communication endpoints, the transport 45 microprocessor available from Intel Corporation of Santa 
interface can negotiate with the telecommunications pro- Clara, Calif. The computer system 100A also includes input, 
vider to ensure that the quality-of-service allocated to the output and storage devices coupled to the CPU 100A, 
telephony connection is consistent with the required quality- comprising a microphone 120 A, a digital video camera 
of-service that is associated with the socket groups. In 110A, an audio speaker 140 A, a monitor 130A, a keyboard 
addition to providing parameters specifying the group 50 andVor pointer input device 150A and a storage device 160A 
quality-of-service, there may also be provided, in accor- which may include magnetic disk storage and/or semicon- 
dance with one aspect of the invention, an indication of a ductor memory storage. The CPU 100A of the computer 
level of guarantee for the socket group, wherein if the system 10 is coupled to a connection oriented telephony 
quaHty-of-service able to be provided by the telephony network 30 by way of a telecommunications interface 170A. 
network does not match the required quality-of-service 55 The telephony in this embodiment of the invention corn- 
associated with the socket group, the transport interface will prises an Integrated Services Digital Network (ISDN), and 
accept the telephony connection depending upon the value the telecommunications interface thus comprises an ISDN 
for the level of guarantee for the socket group. interface device as are known in the atf. In other applications 

In one form of the invention the method includes creating of the invention, however, a different form of telephony 

afurther socket at said first computer, after the establishment 60 network may be employed, such as the plain old telephony 

of said telephony connection, designating said further socket service (POTS) portion of the Public Switched Telephony 

as belonging to said first socket group, and establishing a Network (PSTN), in which case the telecommunications 

connection to a corresponding socket at said second com- interface 170A may be a modem device, 

puter by way of said telephony connection. The method of Also coupled to the telephony network 30 is a computer 

the invention may also include, during the step of establish- 65 system 20 (sometimes referred to as the remote site or 
ing said telephony connection, a step of placing a telephone endpoint), which preferably comprises a similar hardware 
call on said telephony network on the basis of the deter- configuration to the local site computer system 10. Thus, the 
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remote site computer system 20 includes a CPU 100B Dumas, Sams Publishing, 1995), the disclosure of which is 

coupled to peruAeral devices such as a microphone 120B. a also incorporated herein by reference, 

video camera UOB, an audio speaker MOB, amomtor 130B, PD is a transport layer interface corresponding to layer 4 

data input devices 1S0B and storage device 160B. The in the OSI (ojen Systems Interconnection) seven layer 

telephony network 30 by way of a telecommunications /tc™ tv , * a • j jj . 

interface device 170B f JtraJnritting signals through toe 2™!!^ ln ""f ? T^f 

telephony network and receiving signals herefrom. eme ^* l " ch 1 were ^adequately addressed in either 

TVe computer systems 10 and 20 operate under control of SS? {"*> S °tV t A etba . in ^ s J«- 

software code which is stored, in use* in memory proviaS ln 2*2^5 leo ^Wmdow S fI^pLrform.Som C af the 

in the processing units 1O0A, 100B or storage devices 160A, 10 Sul current WinSock interface 

160B, respectively. The software is executed by the pro- i„a a m •., . ... J - 

cessing units, and comprises a number of leveli of fane- T™J*^^^ provides a standardized inter- 

tionality as illustrated inthe block diagram of FIG. 2.Asuite S^Vl^ "? 1° c ^ tlua mth ^ number 

of software functions 200 is shown^rranged in layeTta „ ° f ^ f ,^°^ ^ w^'^.^f 

HO. 2, comprising an application layer210, an appUcation " f^TT? •J* 0 "? ^F^Z Sp f f T? 

Fogramimng interface hyer (API layer) 220 and a service ^ f T^}° te Used and *» type rf socket desircd - 

Pxo™yer and LT<wS Jy« m TOe Svl« ™ USK '*» ^rf" 1 10 ^ ^ u toa P articular 

F oviderandd e vic*driverlayer230p?ovidesaniter^eto ffSLT^ ^ t^f 

the hardware portions of the computer system (hardware M ^wce T ^* ^ji! 1 *?*^ 

layer 240) whiAmtu ra kterfa C estothePSIN3 0 as shown " ^1^^^ udl( ^ ( the address famUies 

in FIG. 1 ' ' > 40(1 socket types which they support 

t„ ft.. ™»o._. , , . .... Expanded Set of Socket Types— Having access to multiple 

J?i£? ' conf ?™ cln S application is transport protocols generates a needfor additional socket 

^fi* * C ^ ca ^' l layer 210, comprising *deo typeTpfl incorporates an extensive set of socket types 

conferencing apphcauon 212. The purpose of the video „ ^ adopts a n^aningfoj ^ uniform naming ^! 

svsfri^ 8 SI ™ % US6r ° f , COmpU,er vention. Socket type nameldearly indicate communica- 

S tT^fTT, k „ uswtfcoiimutasysto tions Pr°P°ties such as connectedness, reliability, pres- 

^io TL t ^ ^ T? 30 Way ° f ervation rf transmission boundaries, directionaUty a^d 

audio, and data transmissions. A video conferencing appli- isochronicity 

^°?„ ™^ tin8 t * "Tf T!^ 10 f ^ 1 ^ S 30 Shared Sockets-PH introduces a mechanism for a single 

l!rr«Ti °^ ^ S ** socket to «» shared across multiple applications. The 

microphone 120A, the video camera U0A, and keyboard/ baling paradigm is appropriate for bottVWindows 31 

SSLS^ * "Xf ? CTM) a'nd^SvancXlCnment.h^WinZs NT 

SmZ^o^ ^ A f 1 f 4 ° A ' f (TM) and Windows 95 CTM). One or more virtual sockete 

*™l£^ g ac ^™ n ^ d ^ on ° fa 8 nals 35 are created that Preference a single underlying socket, 

tough the tcle^mmuiucaaon mterface 170A. The appli- ^ vi^al socket has an independent notification 

cation 212 is able to provide this functionality by utilizing mechanism, but shares all other aspJcts of me mderS 

functions provided by a dynamic linked library (DLL) of the socket ^pctu, ui mc unaeriying 

applkation programing interface (AH) layer AHs and of Service-pII introduces a number of features 

^fhfZ, T^fr, 1 * 1 I Pr0 ?u dCd ^ mte ?*™* « related to qualiryrf service (QOS). An extended v™ 

SLSS?.^ ^ M t 3,1(1 of the flow speeffication concept^ outlined in IETF RFC 

subsystems (e.g. toe microphone, speaker video camera and ^53 is ^vi. How specs describe a set of character- 

n^nitar) as are known in the art, as well as APIs 222 and ^ p^Jn^ ^ aetw ^X, 

^IbvSL^rrf^ ^ W^on may associate a flow spefwith a soZ at Z 

SS2I^«S^^w5?^^*" 0, ^ Tb 5?* ^O, * 45 *«» 4 request is made. This flow spec indi- 

(son^mes referred to as a ^ parametricatty what level of service is requked and 

S^i^SS^^ ? .1^' alsostipulateshwflexibletheappUcationiswmingtobe 

rrf«e?^ fa? ^SE^^^^-fJ tf me """^ level * ser ^ *• ^ ^ailabfe. An 

S ki teleph , a ° y ^ M 3180 Pr°v«ted, application may retrieve the flow spec associated with a 

^^S^^^^ B ' tOb0amtttiM S ° ^ « deterge me actual levd of service to^e 

Th* AfT ADT a *u a r , • , Qetwrak is willing and/or able to provide. If conditions in 

™ e of ^ ^described, for example, in the the network change resulting in a reduction (or increase) 

/°^ De *! embcr 1993 0«- «. No. 12, m the available service level a notification mechanism is 

pp 13^4), the disclosure of which is incorporated herein by included to indicate this. 

ref ^ eU ^L. ' 1 _ , _ . 55 Other QOS-related features include the ability to form 

The Protocol Independent Interface (PH) specification socket groups and assign a flow spec to the group, support 

defines a network prograrnrning interface for Microsoft . for performing send and receive operations from within 

Windows (TM) which is a proper superset of the Windows interrupt context, and a callback style notification mecha- 

Socket Interface version 1.1, frequently referred to as Win- nisra. 

Sock As such, it is based on the "socket* ' paradigm popu- 60 TAPI Integration— PII is designed to work hand-in-clove 
Prized in the Berkeley Software Distribution (BSD) from with the Windows Telephony API (JAPI) in providing 
the University of California at Berkeley. Like WinSocfc it uniform and consistent access to the data traiisport capa- 
encompasses both familiar Berkeley socket style routines bilities of telephony connections. Applications can estab- 
and a set of Windows-specific extensions designed to allow lish and utilize telephony data connections without mak- 
the pro^ammer to take advantage of the message-driven 65 ing any explicit calls to the TAPI interface (combined 
nature of Windows (TM). A description of WinSock can be TAPI/PII service providers will silently establish tele- 
found, for example, in Prograniming WinSock (Arthur phony connections on behalf of the appUcation). ATAPI- 
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aware application may also obtain direct access to the 
underlying TAN call handle for subsequent manipulation 
of the call using TAP! Conversely, an application may 
use TAPI directly to establish and manipulate calls and 
then use PII to transport data over already-established 
calls An appendix to this specification sets forth Chapter 
4 and Appendix A of the Protocol Independent Interface 
specification Version 1.5 which describes the functions 
implemented by the PII, including those available through 
the WinSock API together with a number of functions 
provided to enable implementation of the present inven- 
tion. Id the description of the preferred embodiment of the 
present invention which is presented hereinbelow, refer- 
ence is made to the functions described in the appendix. 
In a conferencing system according to the preferred 
embodiment of the invention, a plurality of data streams are 
passed between the local site computer system 10 (FIG. 1) 
and the remote site computer system 20 by way of the 
telephony network 30. An example of a software application 
in which the invention can be implemented is the ProShare 
line of personal conferencing products from Intel Corpora- 
tion of Santa Clara, Calif. Preferably each of the computer 
systems 10 and 20 operate under control of a conferencing 
application 212 which is adapted to transmit and receive 
video and audio signals, as well as data signals which may 
originate either from the conferencing application itself or 
from another application running concurrently, such as an 
electronic whiteboard, time management application or the 
like, as are known in the art. 

A typical video conferencing application will require at 
least two channels of communication in each direction. Each 
endpoint should be able to both send and receive video and 
audio data streams. It may also be useful for conferencing 
computer systems to share other data as welL such as data 
relating to another application also running at each endpoint, 
for example a spreadsheet application. The parties operating 
the conferencing computer systems may, for example, wish 
to discuss spreadsheet data by way of the audio and video 
channels whilst being able to manipulate the spreadsheet 
data at each endpoint In order to achieve this at least one 
additional socket at each endpoint is required. Because the 
audio, video and data channels are related it is advantageous 
for them to be transmitted by way of the same telephony 
connection, rather than creating separate telephony 
connections, between the same endpoints, for each channel, 
as might ordinarily be the case. For this purpose the present 
invention provides a mechanism for grouping together a 
plurality of sockets to enable the telephony service provider 
to ascertain that the sockets are related and should share the 
same telephony connection. 

FIG. 3 is a flowchart illustrating the general procedure for 
establishing communications between applications operat- 
ing on remote computer systems. Flow chart portion 300 
illustrates the general procedural steps carried out, for 
I example, by remote site computer system 100B, and flow- 
chart portion 350 shows the steps carried out by local site 
computer system 100A which initiates the connection. The 

r^irmtP tfte computer firft fivntrg at Vfift( ftflp finest cqm- 

nrn i ri n rt iTn -nrirtnint f nt fp 301 . ) l in ing fin ^nrtrtfl ^W ftU™ 
(see appendix). Because the data is to be transmitted by way 
of a connection oriented telephony network, the sockets) 
rrMtftd will hr "messa g e stream" type socket(sl^as oppose d 
to connectionless, datagram type sockets. A name is 
assigned to each created socket, at step 304, using the bindQ 
function, so that the socket can be addressed. The remote site 
application then listens for incoming connections on the 
sockets (step 306) using the listenO function, and waits until 
a connection is detected (steps 308 and 310). 
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When the l nc fl fff te rnrn puter wishes to communicate wit h 
the remote site, it creates at least one socket (step 3521 t o 
Rwra flg a Wai enrfp nint fnr co mmunication with the remote 
site application. The local site computer, using the telephony 
5 service provider and, for example, functions provided by 
TAPI proceeds to establish a telephony connection to the 
remote site connection. The local site application uses the 
WSAConnectExO function in order to establish connections 
between the local sockets and those sockets listening at the 
10 remote site computer, and to form the local sockets into a 
socket group (step 354). When a connection is detected at 
the remote site computer, the WSAAcceptExO function is 
employed to accept the connection from the local site 
sockets (step 312). Additional sockets are typically created 
15 for communication with the local site sockets, while the 
original sockets return to the listening state. The additional 
sockets are formed into a socket group corresponding to the 
local site socket group. Both the local and remote site 
applications then utilize the setsockoptQ function to estab- 
20 lish a priority level for each socket in the group (steps 314, 
356) indicating to the respective service providers which 
sockets are to be given priority for transmission of data via 
the telephony connection. 
When the procedures of flowcharts 300 and 350 reach 
25 steps 316 and 358, respectively, the local and remote 
grouped sockets created by the applications on the local and 
remote site computers are able to exchange data streams. 
The data for each socket is sent via the same telephony 
connection through the respective telecommunications inter- 
30 faces 170A, 170B and the telephony network 30 (FIG. 1). 
The service provider 232 (FIG. 2) may be required to 
translate incoming and outgoing data between the format 
utilized by the application and, for example, an ISDN data 
format, as will be apparent to those skilled in the art Once 
35 communication between the local and remote sockets has 
terminated, the telephony connection is broken and the 
respective local and remote sockets closed (step 360, 318). 

The present invention enables ' a socket group to be 
associated with a particular quality of service (QOS) for the 
40 telephony connection. As is known to those of ordinary skill 
in the telecommunications field, the quality of service of a 
telephony connection is related to telecommunications 
parameters including bandwidth and error rate, which deter- 
mine the quality of the telephony connection. 
45 The basic QOS mechanism in PQ revolves around the 
flow specification (or "flow spec") as described in RFC 
1363. A brief overview of this concept is as follows: 

Flow specs describe a set of characteristics about a 
proposed connection-oriented, unidirectional flow through 
50 the network. An application may associate flow specs with 
a socket (one flow spec for each direction for bi-directional 
sockets) at the time a connection request is made. The flow 
specs indicate parametrically what level of service is 
required and also stipulate how flexible the application is 
55 willing to be if the requested level of service is not available. 
(This ranges from "don't make a connection if I don't get all 
that I asked for", to "here is what I would like but Til take 
anything I can get".) After a connection is established, the 
application may retrieve the flow specs associated with the 
60 socket and examine their contents to discover the level of 
service that the network is willing and/or able to provide. If 
the service provided is not acceptable, the application may 
dose the socket and take whatever action is appropriate (e.g. 
scale back and ask for a lower quality of service, try again 
65 later, notify the user and exit. etc.). 

Even after a flow is established, conditions in (he network 
may change resulting in a reduction (or increase) in the 
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available service level. A notification mechanism is included 
which utilizes the existing PH notification techniques to 
indicate to the application that QOS levels have changed. 
The application should again retrieve the corresponding flow 
spec and examine it in order to discover what aspect of their 
service level has changed. 

Flow specs divide QOS characteristics into the following 
general areas: 

1. Network bandwidth utilization— The manner in which 
the applications traffic will be injected into the net- 
work. This includes specifications for average band- 
width utilization, maximum burst duration and peak 
burst rate. It also includes an indication which the 
network may provide of minimum link bandwidth (i.e. 
how wide the skinniest pipe is between the two hosts). 

2. Sensitivity to delay — Applications indicate a delay or 
latency value as a target for the network, with an 
understanding further reductions in delay below this 
value are of marginal use to the application. A means is 
also provided to stipulate the maximum mount of delay 
variant that can be tolerated. 

3. Willingness to cope with data loss and service 
interruption— Loss properties are expressed in terms of 25 
both overall percentage of lost packets and maximum, 
amounts of burst loss. Service interruption indicates 
how long the application is willing to tolerate loss of all . 
communication with the endpoint before considering 
the connection broken. 

4. Level of service guarantee — Applications are able to 
indicate a range of requirements, from the need for a 
ironclad guarantee to a willingness to accept whatever 
is availahle after merely expressing a hint about QOS 
preferences. 

5. Flow content identification — Applications may select 
from a wide selection of well-known constants to 
identify the media content of a flow. 

6. Cost sensitivity — An indication of how willing the 40 
application is to minimize communications cost to the 
possible detriment of other QOS parameters. 

7. Communications security— Applications may specify a 
particular encryption system or option and identify 
public keys to be used. 

Flow specs are only applicable to DSTREAM style sock- 
ets. An application indicates its desire for a non-default flow 
spec at the time a connection request is made (see 
WSACohnectExO. Since establishing a flow specified con- 
nection is likely to involve cooperation and/or negotiation 
between intermediate routers and hosts, the results of a flow 
spec request cannot be determined until after the connection 
operation is fully completed. After this time, the application 
may use ffetsockqptO to retrieve the resulting flow sp ec 
structures so that it can determine what the network was 
willing and/or able to supply. Also, it is entirely possible that 
QOS conditions may change during the life of a connection. 
A means is provided, therefore, fox a PII service provider to 
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typedef struct FlowSpec { 



hit 
Boat 
float 
float 
float 
ml 
ict 
float 
float 
int 
float 
float 
float 

int 
int 
ict 
int 
int 

char far 



} FLOWSPEC 



iMaxMsgSize; 

fAvgBw; 

fBiasfLength; 

ffiurstRate; 

fMinLinkSpeed 

iCoimectiofiStatiu 

iMinDelaySd; 

MnDelayValue; 

CMaxDe lay Variation; 

QLos&Sensitivity; 

fMaxLostPkts; 

fl-osslnterval; 

EMuBurstLoss; 

iMaxSvc Outage; 
iQuaiOfGuaramee; 
fftowOantent; 
iCostScnsitmty; 
{EncryptionSel; 
♦lnEncryptionKey; 



// MTV: Max message adze: bytes 

// Token Bucket Rate: bytes/sec 

// Token Bucket Size: bytes 

// Max Trans Rate: bytes/sec 

// Size of thinnest pipe: bytes/sec 

// Status of the caonecticm 

// Minimum Delay Noticed: 

// Delay value: usee 

// Max Delay Variation: usee 

// Loss Sensitivity: 

// Max # fast MTU's over . . . 

// Loss Interval in MTU's 

// Burst Loss Sensitivity 

// max U ccasec. tost MTU's 

// Max duration for sve outage: sec 

// Quality of Guarantee 

// flow content «d* n*ttW 

// Cost sensitivity 

// Selected encryption algo 

II Pointer to desired key 
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The sections which follow provide a detailed description of 
each field in the flow spec 
fMaxMsgSize 

This field corresponds to the Maximum Transmission Unit 
(MTU) field in RFC 1363. It describes the maximum sized 
message (in bytes) that the application intends to send over 
the flow. This must, of course, be no larger than the value of 
SO_MAX_DG_JSIZE for the underlying service provider. 
The intent of expressing this value in the flow spec is not to 
provide a hard limit for the application. Rather, it serves two 
different purposes. 

First, it is a convenient unit for expressing loss properties. 
Using the default MTU of the internetwork is inappropriate 
since the internetwork may have a very large MTU, such as 
the 64 Kbytes of IP, but applications and hosts may be 
sensitive to losses of far less than an MTU's amount of data. 
For example, a voice application would be sensitive to a loss 
of several consecutive small packets. 

Secondly, the MTU also bounds the amount of time that 
a flow can transmit, uninterrupted, on a shared media. 
Similarly, the loss rates of links that suffer bit errors will 
vary dramatically based on the MTU size. 
fAvgBw 

This field corresponds to the Token Bucket Rate field in 
43 RFC 1363. It is one of three fields used to define how traffic 
will be injected into the internetwork by the sending appli- 
cation. (The other two fields are fBurstLength and 
fBurstRate.) 

As flow specs are based upon the well-known leaky 
bucket algorithm for flow control, this field and several 
others are described in terms of imaginary tokens and 
buckets. The token rate is the rate at which tokens (credits) 
are placed into an imaginary token bucket, expressed in 
bytes/second. For each flow, a separate bucket is maintained. 
To send a packet over the flow, a host must remove a number 
of credits equal to the size of the packet from the token 
bucket If there are not enough credits, the host must wait 
until enough credits accumulate in the bucket. 
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«Atfft, tu* r~™« ~ZT7>7~r~iJ — " : r vv w Note that ^ fact ^ thc ratc ^ expressed in terms of a 

^ •» , T ld aCCCSS and fnspccl 60 token bucket rate not mean that hosts must implement 

Current flOW SDeCS which Will have nnr. nr mnrm mr»Hifl»H m\r*~ a . . 7T7 



current flow specs which will have one or more modified 
values. 

The MI flow spec structure is defined in the HI header file 
HLh and (also attached in the appendix hereto) and is 
reproduced below for discussion purposes. Portions of the 
comment fields shown in italics indicate the corresponding 
flow spec field identifier as found in RFC 1363. 



65 



. uuv iivnw lUUdl UUpiMUWl 

token buckets. Any traffic management scheme that yields 
equivalent behavior is permitted. The field indicates the 
Dumber of byte credits (Le., right to send a byte) per second 
which are deposited into the token bucket 

The value zero is slightly special. It is used to indicate that 
thc application is not making a request for bandwidth 
guarantees. If this field is zero, then the fBurstLength field 
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must also be zero, and the type of guarantee requested may 
be no higher than predicted service (explained below). 
fBurstLength 

This field corresponds to the Token Bucket Size field in 
RFC 1363. It controls the maximum amount of data that the 
flow can send at the peak rate, and is expressed in terms of 
bytes. More formally, if the burst length is B, and the 
average rate is R, over any arbitrarily chosen interval T in 
the life of the flow, the amount of data that the flow sends 
cannot have exceeded B+<R*T) bytes. 

The imaginary token bucket is filled at the token bucket 
rate. The bucket size (or burst length) limits how many 
credits the flow may store. When the bucket is full, new 
credits are discarded. 

The field is ignored if the f AvgBw field is zero. Note that 
fBurstLength must be greater or equal to fMaxMsgSize. 
Zero is a legal value for the field and indicates that no credits 
are saved. 

fBurstRate 

This field corresponds to the Maximum Transmission Rate 
field in RFC 1363, and is expressed in bytes/second. TTus 
rate limits how fast packets may be sent back to back from 
the host Consider that if the token bucket is full, it is 
possible for the flow to send a series of back-to-back 
packets, with the length of this run equal to the size of the 
token bucket (fBurstLength). If the token bucket size is 
large, mis back-to-back run may be long enough to signifi- 
cantly inhibit multiplexing. To limit this effect, fBurstRate 
bounds how fast successive packets may be placed on the 
network. 

One can think of fBurstRate as being a form of a leaky 
bucket When a packet is sent, a number of credits equal to 
the size of the packet is placed into an empty bucket, which 
drains credits at the burst rate. No more packets may be sent 
until the bucket has emptied again. 

fMinlinkSpeed 

This field is an extension to the RFC 1363 flow spec, and 
is expressed in bytes/second. It is provided as a way for the 
network to supply useful information to the application. 
After a connection has been established, an application may 
examine this field in order to determine the capacity limi- 
tations of the underlying hops which the connection spans. 
All such hops will have a capacity greater than or equal to 
fMinl.inkSpeed. 

A typical way for an application to use this field would be 
to initiate a connection requesting the lowest possible level 
of service. Once the connection is established, the applica- 
tion may then determine that higher levels of service are 
likely possible. It may then elect to either modify its use of 
the socket or perhaps trade its current socket in on one with 
a higher level of. service. 

A value of zero implies that this information is not 
available from the network. This field is undefined for 
unconnected sockets. 

iConnectionStatus 

This field is an extension to the RFC 1363 flow spec. It is 
provided as a way for the network to indicate a change in the 
connection status to the application using one of the follow- 
ing manifest constants as values: OPERATIONAL, 
INTERRUPTED, or SUSPENDED. Topical scenarios might 
include: connection status on our cellular modem link 
changes to INTERRUPTED because our car just drove into 
a tunnel, and then changes back to OPERATIONAL when 
we come out the other side. Later on connection status 
changes to SUSPENDED because we are going into power 
conservation mode. The availability of connection status 
may be especially useful for situations where the iMaxSv- 
cOutage value is fairly long. 
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A value of UNKNOWN implies that this information is 
not available from the network. This field is undefined for 
unconnected sockets. 
fMinDclaySet and fMinDehry Value 

5 These two fields both map to the Minimum Delay Noticed 
field in RFC 1363. Pn uses two fields because in the RFC 
the corresponding value may either be one of a set of 
manifest constants or a floating point number. Hie fMinD- 
elayScl field is used to represent the manifest constant, and, 
if applicable, the fMinDelayValue field is used to store the 

10 floating point value in microseconds. 

The minimum delay noticed field tells the internetwork 
that the host and application are effectively insensitive to 
improvements in end-to-end delay below mis value. The 
network is encouraged to drive the delay down to this value 

15 but need not try to improve the delay further. 

If expressed as a number it is the number of microseconds 
of delay below which the host and application do not care 
about improvements. Human users only care about delays in 
the millisecond range but some applications will be com- 

20 puter to computer and computers now have clock times 
measured in a handful of nanoseconds. For such computers, 
microseconds are an appreciable time. For this reason, this 
field measures in microseconds, even though that may seem 
small. 

25 Manifest constants for iMinDelaySel are as follows: 
NO_DELAY_SENSrnVrTY — the application is not sen- 
sitive to delay 

MODERATE_DELAY__SENSmVirY — the application 
is moderately delay sensitive (e.g., avoid satellite links 
where possible) 
30 NUMERIC_DELAY_SENSnTvTTY — the application is 
sensitive to delay as expressed in fMinDelay Value 
fMaxDelay Variation 

This field corresponds to the Maximum Delay Variation 
field in RFC 1363. It is the difference, in microseconds, 

35 between the maximum and minimum possible delay that a 
packet will experience. If a receiving application requires 
data to be delivered in the same pattern that the data was 
transmitted, it may be necessary for the receiving host to 
briefly buffer data as it is received so that the receiver can 

40 restore the old transmission pattern. (An easy example of 
this is a case where an application wishes to send and 
transmit data such as voice samples, which are generated 
and played at regular intervals. The regular intervals may be 
disturbed by queuing effects in the network and the receiver 

45 may have to restore the regular spacing.) 

The amount of buffer space that the receiving host is 
willing to provide determines the amount of variation in 
delay permitted for individual packets within a given flow. 
The maximum delay variation field makes it possible to tell 

50 the network how much variation is permitted. 

The value of 0, meaning the receiving host will not buffer 
out delays, is acceptable but the receiving host must still 
have enough buffer space to receive a maximum transmis- 
sion unit sized packet from the sending host Note that it is 

55 expected that a value of 0 will make it unlikely that a flow 
can be established. 
iLossSehsitivity, fMaxLostPkts and fLossInterval 
These fields together correspond to the Loss Sensitivity 
and Loss Interval fields in the RFC. 

60 iLossSensitivity takes on one of the following well-known 
values: 

NO_JLOSS_SENSIITVrrY— The application is not sensi- 
tive to loss, relying on higher level protocols if needed 
SOMEULOSS^ENSTTIVTrY— The application is sensi- 
65 tive to loss but is not specifying a numeric requirement. 
Where possible, the network should choose a path with 
minimal loss. 
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NUMERIC_XOSS_SENSniVITY— The application PREDICTED_SVC -REQUESTED— predicted service is 
requires that loss characteristics be as described in fMax- requested but an imperfect guarantee is acceptable. 

ml^J^L k ™ GUARANrEBD_SVC_JREQUIRED — guaranteed service 

rMaxLostPkts specifies the maximum number of MTU * , TT, x 6 

sized packets that £y be lost over an intervT^ng which 5 13 ' ?S te 

fLossInterval MTU sized packets were sent. Thus, taken °° flow ^ 0lAd bc cstebll5hcd - 

together, these values specify an average loss percentage. GUARANTEED _SVC_REQUESTED — guaranteed ser- 

fMaxBurstLoss vice is requested and but an imperfect guarantee is 

This field corresponds to the Burst Loss Sensitivity field in acceptable, 

the RFC. It states how sensitive the application's flow is to Application developers should realize that asking for 

losses of consecutive packets. The field enumerates the 10 predicted service or permitting an imperfect guarantee will 

rnaximum Dumber of consecutive MTU sized packets that substantially increase the chance that a flow request will be 

may be lost A value of zero indicates that the flow is accepted 

insensitive to burst loss. mowContent 

Notematitispcnmssi^letosetmeiLossSeiisitivityfield . ™ «7T * . . « „ 
to simply mdicate some seiisto^ is field represents an extension over the flow spec 
cal limit on the number of consecutive packets that can be defineo in » e NFC. The allowed values are all manifest 
lost, constants which indicate the type of media being transported 
fMaxSvcOutage over the flow. Use of this field is optional. Its purpose is to 
This field represents an extension to the RFC flow spec. provide a simplified alternative to specifying QOS para- 
It indicates to the network a time interval, expressed in 20 metrically. For service providers that are "tuned" to transport 
seconds (not microseconds), during which communications certain types of media, merely identifying the socket as 
^onn^n^L^ * ttt ^ cd t without considering bearing a recognized media type may bc sufficient to identify 
the connection to be pennanenfly broken. A value of zero needed QOS levels. Currently defined values include 
indicates no preference on behalf of the application, and that UNSPECIFIED 
the underlying service provider's default value should be 25 GSM^AUDIO 

^SualOfGuarantee ADPCM_AUDIO 

This field corresponds to the Quality of Guarantee field in E^^^Y 
the RFC. It is expected that the internetwork will likely have J^i^T™ v 
to offer more than one type of guarantee. There are two lNJ->EO_MRV 

unrelated issues related to guarantees. 30 11261 

First, it may not be possible for the internetwork to make MPEG1 

a firm guarantee. Consider a path through an internetwork in MFEG2 

which the last ho p is a n Ethernet. Experience has shown MPEG4 

(e.g., some of the IETF conferencing experiments) that an JPEG 

Ethernet can often give acceptable performance, but clearly 35 SVC JPROVIDER_SPECIFIC— service providers are free 

the internetwork cannot guarantee that the Ethernet will not to define their own constants for media streams with 

saturate at some time during a flow's lifetime. Thus it must values greater than or equal to this, 

be possible to distinguish between flows which cannot iCostSensrtivity 

tolerate the small possibility of a failure (and thus must This field represents an extension over the flow spec 
guaranteed at every hop in the path) and those that can 40 defined in the RFC. The allowed values are manifest con- 
tolerate islands of uncertainty. stents which indicate whether or not the application wishes 
Second, it is presumed that some applications will be able to miinmize any costs associated with a connection to the 
to adapt to modest variations in internetwork performance possible detriment of other QOS parameters. Allowed values 
and that network designers can exploit this flexibility to are: 

allow better network utilization. In this model, the internet- 45 NOT_COST_SENSmVE— the application considers cost 

work would be allowed to deviate slightly from the prom- to be a secondary concern or no concern at all 

lsed flow parameters during periods of load. This class of COSTJSENSniVE— the application considers cost to be a 

service is called predicted service (to distinguish it from primary concern and wishes to rmnunize it where pos- 

guaranteed service). sible. 

The difference between predicted service and service so iEncryptionSel and ipEncryptionKey 

which cannot be perfectly guaranteed (eg., the Ethernet Tliese fields represents an extension over the flow spec 

example mentioned above) is that the imperfect guarantee defined in the RFC. They are used to indicate the appliYa- 

makes no statistical promises about how it might misbehave. tion's choice for encryption algorithms (if any) and also to 

In the worst case, the imperfect guarantee wfll not work at specify a pointer to where an encryption key may be found, 

all, whereas predicted service will give slightly degraded 55 Interpretation of the memory contents pointed to by the 

service. Note too that predicted service assumes that the encryption key pointer is service provider/encryption alco- 

routers and links in a path all cooperate (to some degree) rithm specific. Values for the iEncryptionSel field are also 

whereas an imperfect guarantee states that some routers or service provider specific, with the convention that zero is 

links will not cooperate. used to indicate that no encryption is being requested. 

m^tap! 1 ^ 1 ^ 11651 ... 60 A default flow spec is associated with each socket group 

MO_.CiUARANTEE-no guarantee is required (the host is at the time it is created. Field values for this default flow 

r* J^^!T C " mg dcsircd P^crrnance for the flow) spec are indicated below. In ail cases these values indicate 

INffERFECr_GUARANTEE_JlEQUESTED — an imper- that no particular flow ctaictaista 

JlS£^ . • h ° mthC netWOrk * A PP" c *i<>ns only need to modify values 

PREDICTED _5VC_REQUIRED-predicted service is 65 those fields which they are interested in, but must be aware 

requested and if unavailable, then no flow should be that there exists some coupling between fields as was 

established. described above. 
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SO_JvtAZ_JX3__SIZE for the particular 




service provider 


£AvgBw a 


0, no bandwidth request 


fBurstLcngth = 


0, not applicable because rAvgBw is zeao 


(DUIbUvtiC — 


0, not applicable because fAvgBw is zero 




supplied by network, undefined until 




connection occurs 


iConncctiooStfttus = 


supplied by network, undefined until 




connection occurs 


iMinDchySct = 


NO_JDELAY_SENSriTVrrY 


fMinDelay Value = 


0, not applicable 


fMaxDclay Variation = 


0, not applicable 


DuossScnsitivity = 


NO_JJ3SS_SENSmvnY 


fMaxLostPkts * 


0, not applicable 


fl /)fwTnfrrval - 


0, not applicable 


fMaxBuretLoss = 


0, not applicable 


fMaxSvc Outage =» 


0, use provider defaults for time-out 


tQualOftjuarantee = 


NO-GUARANTEE 


EFlowContenl =» 


UNSPECIFIED 


ICostSensitivity = 


NOT_COST_SBNSrnVE 


iEacryptionSel = 


0, no encryption requested 


ipEncryptionKey = 


NULL X 
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FIG. 4 shows a flowchart 400 of the procedural steps 
which may be undertaken during a conferencing session 
utilizing application software employing an embodiment of 
the present invention. A video conferencing application is 
launched at step 402, which creates an audio socket and 
video socket (step 404) for establishing communication with 
a remote endpoint (also running a conferencing application). 
The sockets are formed into a group, at step 406, and a 
connection to a remote endpoint is specified 
(WSAConnectExO function). The service provider inter- 
prets the remote endpoint address and dials the remote 
endpoint through the telephony network (step 408). The 
service provider utilizes ISDN protocols to determine the 
quality-of-service parameters which are available through 
the telephony network to the remote endpoint at step 410. 
The quality-of-service which is desired for the socket group 
is established by the conferencing application as a flow spec 
and is stored at a location indicated by the pointer CpA- 
Howspec (see WSAConnectExO function). If the available 
quality-of-service parameters at least match the quality-of- 
service parameters required by the socket group (step 412) 
then the telephony connection is established with that 
quality-of-service (step 416) otherwise the connection is 
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declined (step 414). The procedure for establishing a tele- 
phony connection according to an embodiment of the inven- 45 tion indicates a group of sockets which are to pass data over 



transmission when an audio data packet arrives, transmis- 
sion of the video packet is interrupted in order to send the 
audio data having a higher priority. The local and remote site 
computers are thus able to communicate audio and video 
data between their respective conferencing applications, 
with the audio data enjoying priority of transmission so as to 
improve the appearance of continuity to the users. 

During the course of the video conference, the users may 
wish to discuss, for example, a spreadsheet document, with 
each party being able to view and modify the spreadsheet 
from their respective computer. Thus, a spreadsheet data 
sharing application is launched at step 424 in flowchart 
procedure 400, which proceeds to create an additional socket 
and add that socket to the existing socket group (step 426). 
The additional socket is created to enable the spreadsheet 
application running at the local site to share data with the 
spreadsheet application running at the remote site. If addi- 
tional bandwidth is required for transmission of the addi- 
tional data on the telephony connection, the transport service 
provider may re negotiate the quality of service parameters 
with the telephony network (step 428). The application 
determines a priority for the additional socket with respect 
to the audio and video sockets at step 430. In mis instance 
the data sharing socket may be allocated a priority which is 
lower than the audio socket and higher than the video socket 
Transmission of data by way of the data sharing socket 
commences at step 432, with the spreadsheet data being 
multiplexed across the same telephony connection as the 
audio and video data according to their relative priorities. It 
will be apparent to those in the art that more than one data 
sharing application may be utilized at one time, requiring 
additional sockets for each additional application. Steps 424 
to 432 would therefore be repeated for each additional data 
sharing application launched during the conferencing ses- 
sion. At the end of the video conference the sockets utilized 
for communicatLog between the applications are dosed (step 
434) and the telephony connection is terminated (step 436). 

Referring now to FIG. 5, there is shown a flowchart 500 
of procedural steps which may be undertaken by the trans- 
port service provider during establishment of a telephony 
connection in accordance with the preferred embodiment of 
the invention, A request for a telephony connection is 
received by the service provider at step 502 such as from an 
application employing the PII APL The request for connec- 



tion is described in greater detail hereinbelow with reference 
to FIG. 5. 

Once the telephony connection has been established (step 
416), a connection to the socket group at the remote end- 
point is established at step 418, for example by application 
of the WSAAcceptExO function. The priority of sockets 
within the socket group is determined (step 420), in this case 
the audio socket having a higher priority than the video 
socket Communication between the video conferencing 
applications commences at step 422. with data being trans- 
mitted between the respective audio and video sockets 
according to their priorities. This means that since the audio 
socket is assigned a higher priority than the video socket, 
audio data to be sent over the telephony connection is given 
priority of transmission on the telephony connection over 
the video data. For example, if a packet of compressed video 
a packet of compressed audio data are both queued for 
transmission by the transport service provider, the audio data 
will be transmitted before the video data regardless of the 
order in which they arrived for transmission. Indeed, a 
preemptive priority transmission system may be employed 
such that even if a packet of video data is in the process of 
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the telephony connection. The flow spec for the socket group 
is retrieved using the pointer fpSFlowspec (see 
WSAConnectExO function definition) in order to determine 
the quality-of-service which is requested or required by the 
socket group (steps 504 and 506). The service provider 
places a call via the telephony network (step 508) and 
negotiates with the network as to the quality-of-service that 
is available for a telephony connection to the desired end- 
point (step 510). A comparison is made between the quality- 
of-service which is requested for use by the socket group and 
that which is indicated as available by the telephony network 
at step 512. If the available QoS at least matches the 
requested quality of service then the telephony connection is 
completed (step 520) and communication between the local 
and remote site socket groups can commence (step 522). If, 
however, the available QoS does to meet the QoS of the 
socket group flow spec, the flow spec is again examined to 
determine the Quality of Guarantee (iQualOfGuarantee 
field) specified by the socket group. If the QoS available 
from the network is nevertheless acceptable for the socket 
group (step 516), as indicated by the flow spec Quality of 
Guarantee value, even though the service does not neces- 
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sarily match the other flow spec parameters, a connection is 
made at step 520. On the other hand, if the quality of 
guarantee flow spec value indicates that the service available 
is not accept able, such as a GUARANTEED _J5VC__ 
REQUESTED value when the available network QoS can- 5 
not be guaranteed, then no connection is established and the 
procedure terminates (step 518). 

The foregoing detailed description of the invention in 
relation to a preferred embodiment thereof has been put 
forward by way of example only, and it is to be understood IC 
that the features presented therein are not to be considered 
limiting to the scope of the invention which is defined in the 
claims appended hereto. 

What is claimed is: 

1. A method for communicating a plurality of dam streams 1 5 
from at least one first computer process operating on a first 
computer under a socket based transport interface to at least 
one second computer process operating on a second com- 
puter under a socket based transport interface, by way of a 
connection-oriented telephony network, comprising the 20 
steps of: 

creating a first socket group comprising a first plurality of 
socket communication endpoints for use by said at least 
one first computer process on said first computer, said 
first socket group corresponding to a single telephony 25 
connection; 

determining a required quality-of- service associated with 
said first socket group; 

establishing said telephony connection by way of said 
connection-oriented telephony network between said 30 
first and second computers, said telephony connection 
having a quahty-of-service at least equal to said 
required quality-of-service; 

creating a second socket group comprising a second 
plurality of socket communication endpoints for use by 35 
said at least one second computer process on said 
second computer, said second socket group corre- 
sponding to said single telephony connection, and 
establishing a plurality of communication channels 
between each of said first plurality of sockets and 40 
corresponding ones of said second plurality of sockets, 
said plurality of communication channels comprised by 
said telephony connection; and 

transmitting a plurality of data streams between said at 
least one first process on said first computer and said at 45 
least one second process on said second computer by 
way of said plurality of communication channels mul- 
tiplexed on said telephony connection. 

2. A method as claimed in claim 1, wherein the step of 
establishing a telephony connection includes determining an 50 
available quality-of-service from said telephony network to 
said second computer, and comparing said available quality- 
of-service with said required quality-of-service associated 
with said first socket group to determine whether a tele- 55 
phony connection to said second computer having a quality- 
of-service at least equal to said required quality-of-service 
can be made. 

3. A method as claimed in claim 2, wherein said required 
quality-of-service is defined by a flow specification which 60 
includes an indication of a desired minimum data transmis- 
sion rate, a desired maximum transmission delay variation, 
and a desired quality of guarantee for the telephony con- 
nection. 65 

4. A method as claimed in claim 3, wherein if the available 
quality-of-service does not at least equal said required 
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quality of service, said telephony connection is established 
conditional upon the difference between said available 
quality-of-service and said required quality of service, and 
said desired quality of guarantee. 

5. A method as claimed in claim 1, including a step of 
assigning a respective priority value to each socket in said 
first socket group, wherein said transmitting step includes 
transmitting a data stream corresponding to a said socket 

1 having a higher priority in preference to a data stream 
corresponding to a socket having a lower priority. 

6. A method as claimed in claim 5, wherein said trans- 
mitting step includes a step of temporarily suspending 
transmission of data from a socket having a lowest assigned 
priority amongst said first and second plurality of sockets 
comprising said first and second socket groups. 

7. A method as claimed in claim 5, wherein said first 
plurality of sockets comprising said first socket group 
includes a socket for transmission and reception of audio 
data and a socket for transmission and reception of video 
data, the audio data socket being assigned a higher priority 
than the video data socket 

8. A method as claimed in claim 1, wherein said at least 
one first computer process comprises a computer conferenc- 
ing application for exchanging audio and video data with 
said at least one second process, said plurality of first sockets 
including an audio data socket and a video data socket 

9. A method as claimed in claim 8, wherein said at least 
one process includes a data sharing application, and wherein 
said plurality of first sockets includes a data sharing socket 
fox transmission and reception of text and/or graphical data. 

10. A method as claimed in claim 1, wherein said tele- 
phony network comprises an Integrated Services Digital 
Network. 

11. A method as claimed in claim 1, wherein said tele- 
phony network comprises an Asynchronous Transfer Mode 
network. 

12. A method as claimed in claim 1, including the steps of: 
creating a further socket at said first computer, after the 

establishment of said telephony connection; 
designating said further socket as belonging to said first 
socket group, and establishing a connection to a cor- 
responding socket at said second computer by way of 
said telephony connection. 

13. A computer conferencing system for use on a com- 
puter operating under a Windows (TM) operating system 
with a socket based transport interface, comprising: 

a video data source for digitizing visual information so as 

to generate a video data stream; 
an audio data source for digitizing sound information so 

as to generate an audio data stream; 
a display device for displaying incoming video data; 
a speaker device playing Incoming audio data; 
a telephony interface device coupled to send and receive 
data signals by way of a telephony connection on a 
telephony network; 
a processing unit executing a conferencing application, 
the processing unit being coupled to the video data 
source, the audio data source, the display device, the 
speaker device and the telephony interface, the confer- 
encing application including a plurality of sockets 
comprising a socket group, said socket group corre- 
sponding to said telephony connection, said socket . 
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group including an audio data socket for transmitting 
said audio data stream and receiving said incoming 
audio data by way of said telephony interface device 
and a video data socket for transmitting said video data 
stream and receiving said incoming video data by way 5 
of said telephony interface device, said socket group 
being associated with a required quality-of-service, the 
processing unit including a transport interface which 
controls said telephony interface device so as to estab- 



20 

lish a telephony connection on said telephony network 
having a quality-of-service in accordance with the 
required quality of service for said socket group a 
plurality of local sockets to collect data from multiple 
local data servers, and then transmitting that collected 
data over a single socket to the remote workstation 
using a connection with a desired quality of service. 

* * * * * 
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Abstract Text - ABTX (1) : 

In a computer video conferencing system it is often necessary to 
transmit multiple channels of information between remote computers, 
such as a video channel, an audio channel and data sharing channel. A 
socket based transport interface can be utilized to establish 
communication channels between remote computers over a connection 
oriented telephony network, A plurality of sockets are created at 
each endpoint, one for each type of data stream to be transferred 
between the computers. The sockets are formed into a group to 
indicate to the computer transport service provider that the data 
streams from the sockets can utilize the same telephony connection, 
and a quality-of-service specification is associated with the socket 
group so that the telephony connection can be established according 
to the requirements of the socket group. If a new data stream needs 
to be transmitted and there is already a telephony connection 
established, a new socket is created and added to the existing socket 
group. If the newly added socket significantly affects the quality- 
of-service requirements of the socket group, a new quality-of-service 
may be negotiated with the telephony network. 

Brief Summary Text - BSTX (11) : 

In accordance with the present invention, there is provided a 
method for communicating a plurality of data streams from at least 
one first computer process operating on a first computer under a 
socket based transport interface to at least one second computer 
process operating on a second computer under a socket based transport 
interface, by way of a connection-oriented telephony network, 
comprising the steps of: creating a first socket group comprising a 
first plurality of socket communication endpoints for use by said at 
least one first computer process on said first computer; determining 
a required quality-of-service associated with said first socket 
group; establishing a telephony connection by way of said connection- 
oriented telephony network between said first and second computers, 
said telephony connection having a quality-of-service at least equal 
to said required quality-of-service; creating a second socket group 
comprising a second plurality of socket communication endpoints for 
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use by said at least one second computer process on said second 
computer, and establishing a plurality of communication channels 
between each of said first plurality of sockets and corresponding 
ones of said second plurality of sockets; and transmitting a 
plurality of data streams between said at least one first process on 
said first computer and said at least one second process on said 
second computer by way of said plurality of communication channels 
multiplexed on said telephony connection. 

Detailed Description Text - DETX (117) : 

FIG. 4 shows a flowchart 400 of the procedural steps which may be 
undertaken during a conferencing session utilizing application 
software employing an embodiment of the present invention. A video 
conferencing application is launched at step 402, which creates an 
audio socket and video socket (step 404) for establishing 
communication with a remote endpoint (also running a conferencing 
application) . The sockets are formed into a group, at step 406, and a 
connection to a remote endpoint is specified (WSAConnectEx ( ) 
function) . The service provider interprets the remote endpoint 
address and dials the remote endpoint through the telephony network 
(step 408) . The service provider utilizes ISDN protocols to determine 
the quality-of-service parameters which are available through the 
telephony network to the remote endpoint at step 410. The quality-of- 
service which is desired for the socket group is established by the 
conferencing application as a flow spec and is stored at a location 
indicated by the pointer CpAFlowspec (see WSAConnectEx ( ) function). 
If the available quality-of-service parameters at least match the 
quality-of-service parameters required by the socket group (step 412) 
then the telephony connection is established with that quality-of- 
service (step 416) otherwise the connection is declined (step 414) . 
The procedure for establishing a telephony connection according to an 
embodiment of the invention is described in greater detail 
hereinbelow with reference to FIG. 5. 

Claims Text - CLTX (5) : 

creating a second socket group comprising a second plurality of 
socket communication endpoints for use by said at least one second 
computer process on said second computer, said second socket group 
corresponding to said single telephony connection, and establishing a 
plurality of communication channels between each of said first 
plurality of sockets and corresponding ones of said second plurality 
of sockets, said plurality of communication channels comprised by 
said telephony connection; and 
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